Traditionally software applications and architectures that accommodate the form flow of electronic forms use server-side programs to determine the processing, or routing, of a given form. These approaches use data and tables stored separately from the electronic form itself to define a set of rules and routing guidelines. In these approaches the server-side program will interpret some data from the electronic form submitted from the client and then using these server-side routing guidelines will perform some task to process the electronic form. An example of this can be found in JetForms use of what are called roles, which are defined using a special software application (separate from the electronic form) called the InTempo Role Builder (defined in white paper http://www.jetform.com/prodsol/whitepapers/intempo_ps.html). These approaches require that all possible routing scenarios are defined ahead of time and that all users within a user community have their roles within those scenarios defined. This pre-defined routing strategy requires a large amount of data that would prohibit inclusion in the electronic form that would be transmitted from one user to another over the server.
Software applications targeted at businesses often provide functionality that automates, via a client (web browser or other client side application)/server model, a collaborative business process where successive users approve or reject information presented to them. Example applications are Enterprise Resource Planning (ERP) applications and large point solutions in the Time and Expense (T&E), Procurement, and Customer Relationship Management space. Example companies in these markets are SAP, PeopleSoft, Siebel, J. D. Edwards, Concur, etc. An example business process where this collaboration is automated would be an Expense Report. For example, a blank Expense Report form may be obtained by a user who then enters data into the Expense Report. The user then needs to route that Expense Report to an approver (like their Manager). The “routing” of the Expense Report may be done by any number of methods in a software (electronic) system.
A common implementation is the concept that each user of the system has a work queue, which is essentially an electronic version of the physical In & Out box a businessperson would have on their desk. In existing software applications, routing is accomplished in the following manner. A user starts a process (fills out a blank form and submits it). The routing of the form to the next user (the first approver) is done in most cases by the system, which looks up the next user by accessing a predefined process map and then moving the electronic form to that user's queue. This predefined routing in most conventional systems needs to be defined beforehand for every user, for every kind of process in the system, and is role specific in that an electronic organization chart must be created. Each user's role (individual contributor, 1st to n level manager, Director, VP, SVP, etc.) must be pre-defined in the electronic organization chart so that a process map for each user who may start a process can be defined and followed.
This predefined routing model is flawed in that personnel changes (people leaving the company or changing jobs and responsibility levels) in large organizations are very frequent. A user submitting a new process may cause the system to attempt to route to a user, who five minutes previous left the company. In this case, the process goes into a black hole or the system must allow an adhoc routing back door to get around the out-of-date predefined process.
Thus, a better electronic form routing system is needed, which does not require implementing the complicated, time consuming and high maintenance role based electronic organization chart approach.